@Rick-Anderson @tdykstra @wadepickett ... Sébastien Sougnez's Twitter link in an article byline broke and appears in the build report. I'm fixing it on this PR, but it will go in later today because this needs a PU review from Mackinnon.

I'm a bit worried that our change in structure to the Blazor.start() 'options' parameter is going to create a pit of failure for customers, especially if they're doing a Blazor WebAssembly Standalone application. If a customer gets it wrong by accident and adds the webAssembly property rather than defining these options on the top level, there's no clear indication when they run their app that they did anything wrong. It just appears to "not work" silently.

In hindsight, it would have been great if we adjusted blazor.server.js and blazor.webassembly.js to also accept the new 'options' format and normalize it to the old one. It would have made docs a little easier too, because we wouldn't have to worry about distinguishing between the two cases. Perhaps that's something we can change in .NET 9 (or a servicing release?).

[me] In hindsight, it would have been great if we adjusted blazor.server.js and blazor.webassembly.js to also accept the new 'options' format and normalize it to the old one. It would have made docs a little easier too, because we wouldn't have to worry about distinguishing between the two cases. Perhaps that's something we can change in .NET 9 (or a servicing release?).

Filed dotnet/aspnetcore#51611 to track this.

@MackinnonBuck @danroth27 ... I went with showing both standalone WASM and Blazor Server in a SxS format with BWA scripts for >=8.0, and I leave WASM/Server code to appear for <8.0. I didn't use pivots ... just vanilla versioning.

🛑 NOTE TO SELF ✋

If we show Blazor Server scripts >=8.0, I'll need to UN-version the _Host.cshtml/_Layout.cshtml content for >=8.0 for these Blazor.start scenarios because all of the _Host/_Layout content was 🔪 out for general BWA coverage in >=8.0 content.

UPDATE: It took a few more commits, but I think it's good for a look now. If this approach is ok for the code, I'll just need to circle back for _Host.cshtml/_Layout.cshtml updates so that Blazor Server folks can find where the script lives and where to add their Blazor.start code.

UPDATE: There's a new Blazor script location section now in the Project Structure article. I'll be linking to it from across the doc set for Blazor script location.

@MackinnonBuck ... The last commit:

• Adds a section to the Project Structure article explaining the location of the Blazor script.
• Refactors the lead-in remarks of the Fundamentals > Startup article to refer to the new location section for location information.
• I'll cross-link the new location section around the docs soon where the script is mentioned on PR later. I opened Cross-link new Blazor script location section #30866 to track that work separately.

I think we can leave the remaining references (placeholder remarks) in the Fundamentals > Startup article as they are.